<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3//EN">
<HTML><HEAD>
<TITLE>User's Guide - Presentation: Issues and Techniques</TITLE>

<META HTTP-EQUIV="abstract" CONTENT="IBM Visualization Data Explorer User&#39;s
Guide">
<META HTTP-EQUIV="contact" CONTENT="IBM Visualization Data Explorer
(ibmdx@watson.ibm.com)">
<META HTTP-EQUIV="owner" CONTENT="IBM Visualization Data Explorer
(ibmdx@watson.ibm.com)">
<META HTTP-EQUIV="updated" CONTENT="Tue, 16 Sep 1997 ">
<META HTTP-EQUIV="review" CONTENT="Fri, 14 Aug 1998 ">

<META HTTP-EQUIV="keywords" CONTENT="GRAPHICS VISUALIZATION VISUAL PROGRAM DATA
MINING">
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">
</HEAD><BODY BGCOLOR="#FFFFFF" link="#00004b" vlink="#4b004b">
		<TABLE width=510 border=0 cellpadding=0 cellspacing=0>
			<TR>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=80 HEIGHT=1></TD>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=49 HEIGHT=1></TD>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=24 HEIGHT=1></TD>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=100 HEIGHT=1></TD>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=3 HEIGHT=1></TD>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=127 HEIGHT=1></TD>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=6 HEIGHT=1></TD>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=50 HEIGHT=1></TD>
				<TD><IMG SRC="../images/spacer.gif" WIDTH=71 HEIGHT=1></TD>
			</TR>
			<TR>
				<TD colspan=9><IMG src="../images/flcgh_01.gif" width=510 height=24 border="0" alt="OpenDX - Documentation"></TD>
			</TR>
			<TR>
				<TD colspan=2><A href="../allguide.htm"><IMG src="../images/flcgh_02.gif" width=129 height=25 border="0" alt="Full Contents"></A></TD>
				<TD colspan=3><A href="../qikguide.htm"><IMG src="../images/flcgh_03.gif" width=127 height=25 border="0" alt="QuickStart Guide"></A></TD>
				<TD><A href="../usrguide.htm"><B><IMG src="../images/flcgh_04d.gif" width=127 height=25 border="0" alt="User's Guide"></B></A></TD>
				<TD colspan=3><A href="../refguide.htm"><IMG src="../images/flcgh_05.gif" width=127 height=25 border="0" alt="User's Reference"></A></TD>
			</TR>
			<TR>
				<TD><A href="usrgu065.htm"><IMG src="../images/flcgh_06.gif" width=80 height=17 border="0" alt="Previous Page"></A></TD>
				<TD colspan=2><A href="usrgu067.htm"><IMG src="../images/flcgh_07.gif" width=73 height=17 border="0" alt="Next Page"></A></TD>
				<TD><A href="../usrguide.htm"><IMG src="../images/flcgh_08.gif" width=100 height=17 border="0" alt="Table of Contents"></A></TD>
				<TD colspan=3><A href="usrgu062.htm"><IMG src="../images/flcgh_09.gif" width=136 height=17 border="0" alt="Partial Table of Contents"></A></TD>
				<TD><A href="usrgu080.htm"><IMG src="../images/flcgh_10.gif" width=50 height=17 border="0" alt="Index"></A></TD>
				<TD><A href="../srchindx.htm"><IMG SRC="../images/flcgh_11.gif" width=71 height=17 border="0" alt="Search"></A></TD>
			</TR>
		</TABLE>
		<H2><A NAME="Header_410" ></A>A.5 Presentation: Issues and Techniques
</H2>
		<A NAME="IDX972"></A><A NAME="IDX973"></A>
<P>
Visualization is used to represent natural phenomena that are inherently
visual themselves, but probably more often, it is used to
"visualize" non-visual phenomena.
The process of making something visual means making choices on the part
of the program author or designer.
Clearly, without a sound scientific basis for these choices, this can
become a purely artistic venture.
While computer graphics can be used to make beautiful artwork, that is
presumably not the point of using visualization to help study,
analyze, or understand data.
This does not mean that you should forego good design in making your
visualization scene understandable.
Remember and use the "rules" of design mentioned above, including
proper, legible annotation, reasonable choices for colors, and so on.
These things are determined partly by the medium you are working in and
partly by the rules of good layout and design.
<P>
But what color is a magnetic field?
What color is hot?
What color is high?
How fast should molecules vibrate?
How quickly should a metallic surface move as it changes phase?
These decisions must be made by the program author.
Probably the three most critical choices are color, scale, and speed.
<P>
In visualization, color is used precisely because it is <I>not</I>
realistic.
That is, to emphasize an area of interest, red is
commonly used.
Or, a strong contrast color can be used against a field of fairly
neutral colors.
However, there are some cultural color choices that you may find
inappropriate to violate.
For historical and to some degree natural reasons, we tend to make
color gamuts that indicate red as the "highest" and blue
the "lowest."
Particularly with temperature, we can associate blue with "cool"
or water/ice color, and red with "hot" or flame/sun color.
To some degree, this gamut is related to the color of heated metal, but
of course, the metal color does not pass through green at the
midway point, and the color scale does not end at white
like white-hot metal, so this too is only a loose analogy.
But try inverting a color map of temperature to make red cool and blue
hot and you will probably find you have to perform mental gymnastics
to interpret it "correctly."
If you are mapping altitude, however, red is not necessarily best
associated with the "high" point: after all, the highest
altitudes are snow-covered and lower altitude deserts are
frequently "red-hot"!
Actually, color-mapping altitude is almost purely an artistic endeavor,
but at least it has a long history and literature in cartography.
Consulting the "traditional" textbooks for a field may indicate
how users in that discipline "prefer" things to be mapped.
It is generally unwise to start a new schema for your visualization if
you wish it to be immediately accessible to other viewers familiar
with the discipline.
But relating new ways of visualizing data to the old methods may be a
good way to provide new insights for everyone involved.
<P>
Remember that to use interpolation, the basis of your assumptions is
that the phenomenological space studied is continuous and linear.
If you have reason to believe the sampling was not done over a domain
that can be linearly interpolated, you should certainly not be
using linear interpolated images to understand the data.
You may need to collect more data on a finer grid to resolve such
problems.
Since Data Explorer supports irregular grids, this is not a problem for the
software, as long as you provide the correct data sampling.
Also, be aware that trying to read too much detail out of an image is
an error.
You cannot accurately assess detail at a resolution equal to or less
than your sampling rate (the Nyquist law states that you cannot
derive valid signal from noisy information at less than
twice your sample rate).
For example, occasionally, you will see peculiar color artifacts that
arise when data and therefore interpolated colors change rapidly
at the scale of the sampling mesh.
In those cases, the best bet is to "zoom out" to see only the big
picture: do not try to read between the lines!
<P>
Related to sampling rate in space is sampling in time.
Be sure you have collected enough time step detail to ensure you have
not completely missed some important transitional state that
might have occurred in the middle of an animated sequence.
It is acceptable to skip through the entire range of time steps
during the development of your animation, but be sure to fill
in the gaps before the final presentation is analyzed.
<P>
As in traditional statistical plotting, a computer can all too easily
permit the author to scale objects or graphs into wildly
distorted aspects.
In charting, there are some simple
rules of thumb: it is often suggested that the aspect
ratio (height/width) be about 0.75 to 1.00 for a
2-dimensional chart.
This may require rescaling one axis, and naturally, both axes and their
scales must be shown.
It is also bad form to start an axis at one point then create a break
part way along, causing a visual foreshortening.
And it is also inappropriate to start an axis at a point other than the
origin if the intent of the chart is to represent absolute amounts
of quantities being compared side by side.
All of these rules of thumb are employed to make "good" charts;
nevertheless, these rules are too often violated even in the mainstream
media.
<P>
Unfortunately, these traditional rules of scale do not help us much
when we create 3-dimensional objects of arbitrary shape.
So it becomes incumbent upon you to make sensible decisions in
depicting objects never before seen by any viewer.
It will be very easy to exaggerate a 3-D height field by changing the
scale factor in Rubbersheet.
You can make the one high point in the data leap as high as
Mt. Everest.
If that point is in fact a special value in your data, this may be
an appropriate thing to do.
If not, you may wish to choose a scale better suited to depicting the
entire surface.
On the other hand, if there are peaks, you must avoid "crushing"
the entire surface to lessen the high points.
Doing so could lead to potential misinterpretation of your results.
<P>
For many researchers, Data Explorer will be the first program they have
used that permits them to create and view animation or motion
playback of their data.
This new temporal dimension is often a source of problems until the
author gets the hang of things.
Here are a few tips as you develop your own "moving pictures."
<P>
First, remember that your viewers have never seen this phenomenon
before.
Give them a chance to absorb it: looping the entire sequence is
usually helpful.
You do not want to bore the viewer to death, but visualization is
not a TV commercial: cutting to a new scene every two seconds
is not a good editing technique for communicating difficult
visual information.
As we discussed in the section on Animation, showing the same sequence
at more than one speed helps a viewer notice different information in
the very same scene.
<P>
Visualization allows users (fortunately) to wildly distort time
scales.
One video may show the movement of tectonic plates, another the
gyrations of atoms in a gas.
One scale is millions of years, the other billionths of seconds, but
both are brought into the "video" scale of one frame every
thirtieth of a second.
Clearly, you must use some kind of clock annotation, especially if you
plan to change playback rates, and even more importantly, if you plan
to show different data sets using the same type of animation.
The user must be given a proper sense of how two animations compare in
their duration if sense is to be made of these animated sequences.
<P>
However, humans are not particularly good at visual comparison from
memory.
We are good at pattern recognition and comparison, but we have
inadequate temporal rate memories;
we do not remember detail in relation to time because we do not have
good time-keeping reference systems in our brain.
That implies that you must either choose to show comparisons based on
precisely the same time duration and playback rate (thus factoring
out the time dimension), or, much better, show two motion
sequences at the same time in the same picture.
One way to accomplish this is to render two sets of images, then use
the Arrange module to construct an animation showing the two
sequences side by side.
This technique is important if the two phenomena vary in a
scientifically critical way during the process;
for example, if one phase change event is virtually complete after
40% of the entire time step series and another phase change
after 60%, this may represent one of the important
findings of your research.
But if you show the viewer first one sequence, then the other, very few
people will be able to make a solid visual comparison from their
memory.
It is much more visually impressive to show the two phase change
simulations side by side, starting at the same time, and
proceeding for the same number of time steps.
<P>
Animation must also proceed quickly enough for the mind&#39;s eye to
perceive it as animation.
Imagine taking each time step of your simulation, making a 35mm slide,
and loading up a slide carousel with ninety slides.
A viewer who is shown each slide for 5 seconds is unlikely to
perceive the "motion."
Put on videotape, the same sequence of images takes only 3 seconds.
This may be too fast: the entire event may flash by too
fast for the viewer to see any change.
You may need to double-record each image (i.e., slowing things down
by one-half) making the video take 6 seconds.
Another way (more computationally expensive) is to generate twice as
many raw data files and twice as many images.
This will yield smoother animation, but may be too costly for your
resources.
Of course, some events can be shown in 3 seconds:
maybe everything stays the same for 1.5 seconds, then
"pops" into a new configuration.
Slowing this down too much might hide the importance of the sudden
transition to a new state.
Again, you, the user familiar with the field and with the phenomenon
become a judge and a designer.
You have to make wise decisions based on a desire to accurately and
honestly depict the behavior under study with the purpose of
illuminating other viewers, not impressing them with
spectacular computer graphics displays.

		<P>
		<HR>
		<DIV align="center">
			<P><A href="../allguide.htm"><IMG src="../images/foot-fc.gif" width="94" height="18" border="0" alt="Full Contents"></A> <A href="../qikguide.htm"><IMG src="../images/foot-qs.gif" width="94" height="18" border="0" alt="QuickStart Guide"></A> <A href="../usrguide.htm"><IMG src="../images/foot-ug.gif" width="94" height="18" border="0" alt="User's Guide"></A> <A href="../refguide.htm"><IMG src="../images/foot-ur.gif" width="94" height="18" border="0" alt="User's Reference"></A></P>
		</DIV>
		<DIV align="center">
			<P><FONT size="-1">[ <A href="http://www.research.ibm.com/dx">OpenDX Home at IBM</A>&nbsp;|&nbsp;<A href="http://www.opendx.org/">OpenDX.org</A>&nbsp;] </FONT></P>
			<P></P>
		</DIV>
	</BODY></HTML>
